The technology described herein relates to data processing systems in which an accelerator, such as a graphics processing unit, a video accelerator, or a digital signal processor, etc., acts as a common, shared resource for a plurality of applications (such as games, productivity applications, browsers, etc.), and in particular to a method and apparatus for dispatching tasks from plural applications to the common, shared accelerator resource.
In arrangements where an accelerator such as a graphics processing unit acts as a shared resource for plural applications, then when an application requires the accelerator to perform a task, the information needed by the accelerator to perform the task must be provided to the accelerator. This is usually done by providing a set of one or more registers for the accelerator that act as an input/output interface for the accelerator that can store information needed by and provided by the accelerator when performing the task. Then when an application such as a game, wishes the accelerator to perform a task, it will make an operating system call to that effect, and the operating system driver for the accelerator will then schedule the task for the accelerator and write the appropriate task information to a register of the accelerator's input/output interface when the task is to be performed. Where the system supports plural virtual machines, there will typically also be a hypervisor that interfaces between the respective operating system and the accelerator input/output interface register(s) as well.
FIG. 1 illustrates this and shows a system 1 in which an accelerator 12 that comprises an execution unit 2 and a scheduler 9 acts as a common shared resource for plural applications (app) 3 executing on respective virtual machines (VM) 4, 5. (As shown in FIG. 1, and as will be appreciated by those skilled in the art, each virtual machine 4, 5 comprises a respective operating system (OS) 6, 7 that is executing on a common processor to provide the “virtual machine”, and there are respective applications 3 operating within each operating system (virtual machine) that will then use the execution unit 2 as a resource.)
As discussed above, in order to allow the applications to use the execution unit 2 to perform tasks, the execution unit 2 has an associated input/output interface 11 comprising one or more associated sets of physical registers (slots) 8 that act as input/output interfaces for submitting tasks to the execution unit 2 (and thus to the accelerator 12) and that the respective operating system 6, 7 can store information needed by the execution unit 2 in when the execution unit 2 (the accelerator) is to perform a task for a given application.
FIG. 1 shows a system with four sets of register input/output interfaces 8, although other arrangements would, of course, be possible. As shown in FIG. 1, and as discussed above, when an application wishes to use the execution unit 2 to perform a task, it will access a set of the input/output registers 8 of the execution unit 2 via its respective operating system.
FIG. 1 also shows a scheduler 9 that acts to arbitrate between and schedule tasks in the register input/output interfaces 8. As shown in FIG. 1, the system will also include a hypervisor 10 that interfaces between the respective virtual machines (operating systems) 4, 5 and the register input/output interfaces 8 of the accelerator (execution unit) 2.
The Applicants believe that there exists scope for improvements to arrangements for dispatching tasks to an accelerator that acts as a common, shared resource to a plurality of applications.
Like reference numerals are used for like features throughout the drawings where appropriate.